今気づいたんですが，ユーザーを削除する際にfirebaseからも削除する必要があると思います．

そうだったのですが、面倒そうだったので目を背けていました。
仮にfirebaseからも削除する場合、firebaseとDBの両方から完全に消す必要があり、

1. firebase->DBの順で削除
2. DB->firebaseの順で削除
   という2つの戦略が取れると思います。

この2つの中では、後者の方が良いと思っています。

前者は、DBの削除に失敗した場合やコネクションが失敗した場合にfirebaseから削除したデータを再登録する必要があります。それに対し、後者はfirebaseの処理に失敗したときにDBに張っておいたトランザクションをロールバックすれば良いので実装上もよさそうです。

どうでしょうか？

後者がよいと思います．
指摘されている通りこっちのDBでのロールバックは簡単ですが，firebaseで再登録するのは不可能な気がするので．
またユーザーがfirebaseに存在してDBに存在しない状態は想定されています(firebaseで認証した直後)が，逆は想定していないので失敗したときの動作が読めないというのもあります．

その方向で修正します。

infra層でfirebaseとuserの2つに跨っているため、contextにトランザクションを持たせることとします。
ひとまず発表が始まったので、実装はあとでやります。

userRepoとauthRepoのDeleteをmockを用いてControllerでテストする場合、DoInTx()の内部で別のモックを呼ぶ必要がありテストが出来ていません。
ひとまずテストは消したのですが、イマイチ納得いっていないのでテストの仕方についてアイデアがあればコメントしてほしいです。

transactionの設計自体は特に問題は無いと思いました！
DoInTxのモックは

mock.EXPECT().DoInTx(gomock.Any(), gomock.Any()).DoAndReturn(
    func(ctx context.Context, f func(ctx context.Context) error) error {
        return f(ctx)
    })

とかでいけませんか？（今手元にPCないので変なコード書いてるかもしれませんが、要はgomockのDoAndReturnを使えないかということです。)

ControllerのテストではDoInTxは引数の関数をそのまま実行するモックにしたら良いのではないでしょうか！